home *** CD-ROM | disk | FTP | other *** search
/ Mac Magazin/MacEasy 8 / Mac Magazin and MacEasy Magazine CD - Issue 08.iso / Sharewarebibliothek / Utilities / suntar2.03 / speed tests < prev    next >
Text File  |  1994-12-20  |  8KB  |  213 lines
  1. Times (in seconds) on a Macintosh LC with 40MB hard drive (access time 26 msec)
  2. When not specifed, the times are with almost all INITs disabled
  3. (there where only a couple which load themselves before the INIT manager
  4. and SuperClock, which was used to measure speeds by subtracting the
  5. initial and final times)
  6.  
  7. ••••un-BinHex (ram disk -> hard disk, 900k file)
  8.  
  9. ZipIt: an error message and the extraction failed
  10. suntar 1.1 (.hqx.tar)  210 sec    (the slowest unBinHexer in the world...)
  11. deHQX 2.0                 150 sec  (ram-ram) 175 sec (HD->HD) 
  12. Stuffit 1.5.1        146 sec
  13. suntar 1.2.1         137 sec            (I carefully optimized the algorithm, but unfortunately
  14.                                 that was not the bottleneck)
  15. Stuffit Deluxe 3    125 sec
  16. Downline    1.1     125 sec
  17. BinHex 4.0              90 sec
  18. Compact Pro 1.3.3    49 sec (with or without INITs: no event handling, no background
  19.                             operation, the Macintosh does nothing else until the extraction
  20.                             finished: I never liked this way to speed up an application)
  21. suntar 1.3.3        43 sec (48 with INITs)    (introduced disk buffering, and the
  22.                         optimizations introduced in 1.2 may now show their strength)
  23. BinHqx DA (32k buffer size)        36 sec (38 with INITs)
  24. suntar 2.0            33 sec    (36 with INITs)       (uses a look-up table to compute the
  25.                                         CRC error checking: pole position !!!)
  26.                                 
  27. ••••compressed PackIt extraction (ram disk -> hard disk, 900k file)
  28.  
  29. Downline: an error message and the extraction failed
  30. PackIt III                    315 sec (320 sec with INITs)
  31. suntar 1.2.1      156 sec  (175 sec with INITs)
  32. Stuffit Deluxe 3  130 sec
  33. Stuffit 1.5.1        120 sec
  34. unpit 0.1                    105 sec
  35. unpit 0.3 (compiled with Think C 5, I had the source but could not find the application)
  36.                   100 sec
  37. suntar 1.3.3      88 sec        (no change to the algorithm, but benefits from I/O buffering)
  38. suntar 2.0 beta 8   66 sec    (uhh, in suntar 1.3 I'd forgotten to fully enable buffering !
  39.                             And obviously the faster CRC routine helps)
  40. suntar 2.0        42 sec    (optimized the routine: it's not nice being
  41.                             proud of something which I knew was not the
  42.                             best I could do)
  43.  
  44. ••••non-compressed PackIt extraction (ram disk -> hard disk, 900k file)
  45.  
  46. PackIt III             225 sec
  47. suntar 1.2.1   100 sec
  48. StuffIt 1.5.1   65 sec
  49. StuffIt Deluxe 65 sec
  50. suntar 1.3.3    40 sec
  51. unpit 0.1                29 sec
  52. unpit 0.3                28 sec
  53. Downline       23 sec
  54. suntar 2.0 b8  18 sec       (the gain from 1.3.3 to 2.0 b8 is 22 sec: same file, same gain)
  55. suntar 2.0     12 sec
  56.  
  57. ••••tar extraction (floppy disk->ram disk, a directory with many files,
  58.     end of archive at sector 2556)
  59.  
  60. suntar 1.1      140 sec  (187 with INITs)
  61. suntar 1.2.1   140 sec  (185)
  62. StuffIt Deluxe (.tar file on a HFS floppy)  75 sec (+16 for reading
  63.     the directory + the time to select all the files in the scrolling list)
  64. tar 3.0                51 sec     (59)
  65. suntar 2.0   51 sec     (58)        (the accuracy of measurements can't guarantee a
  66.                                     1 sec difference but suntar 2.0 performs some tests
  67.                                     to identify long pathnames and it is reasonable
  68.                                     to expect a small speed decrement over 1.3.3)
  69. suntar 1.3.3 50 sec        (56)
  70.  
  71. (suntar 2.0: save sectors 0 to 2556 36 sec, Copy disk archive to file 47 sec)
  72.  
  73. ••••tar extraction (file on hard disk->ram disk, 2556 sectors archive)
  74.  
  75. suntar 1.1   96 sec   (138 sec with INITs)
  76. suntar 1.2.1 92 sec      (135 sec)
  77. StuffIt Deluxe 3.0.6   30 sec (33 with INITs) (+5 to read the directory)
  78. suntar 1.3.3 22 sec        (28)
  79. suntar 2.0   22 sec     (27)
  80. tar 3.0      18 sec     (21)
  81.  
  82. ••••tar extraction (HD->HD, 900k file)
  83.  
  84. suntar 1.1       92 sec
  85. suntar 1.2.1    90 sec
  86. untar 1.0         60 sec    (it's a new program and I did not perform other tests on it)
  87. StuffIt Deluxe  21 sec
  88. suntar 1.3.3    17 sec
  89. suntar 2.0      17 sec
  90. tar 3.0         12 sec
  91.  
  92. ••••uudecode (ram disk -> hard disk, 900k file)
  93.  
  94. uulite 1.3                    300 sec    (what a pity, its user interface is very good, but so slow…)
  95. UMCP™ Tools        95 sec
  96. tiger             65 sec (ram->ram)  120 sec (HD->HD)
  97. un*files (bug fixed and recompiled with ThC 4)   55 sec (ram->ram) 105 sec (HD->HD)
  98. StuffIt Deluxe   46 sec
  99. suntar 2.0         29 sec
  100. uuparse                        23 sec
  101. uutool 2.32       20 sec
  102.  
  103. ••••uuencode (another file, HD->HD)
  104.  
  105. uulite 1.6                    220 sec
  106. StuffIt Deluxe     29 sec
  107. suntar    2.03          14 sec
  108. UUTool    2.32         12 sec
  109. UUparser 1.7.1    12 sec
  110.  
  111. ••••Macbinary extraction (HD->HD, 900k file)
  112.  
  113. UMCP™ Tools    100 sec
  114. suntar 1.2.1        96 sec
  115. BinHex 5.0      29 sec
  116. StuffIt Deluxe  24 sec
  117. MacBinary II+   17 sec
  118. suntar 1.3.3    17 sec
  119. suntar 2.0      17 sec
  120. suntar 2.0 (with double-sized buffers) 14 sec
  121. MacBinary 1.01  12 sec
  122. ZipIt            7 sec (but in a different configuration, also suntar was
  123.                     a couple of seconds faster that day. Since ZipIt is a large program,
  124.                     probably it uses a huge buffer)
  125.  
  126. ••••tar creation (HD->ram disk, 700k directory)
  127.  
  128. StuffIt Deluxe  28 sec
  129. suntar 2.0      24 sec
  130. tar 3.0         21 sec
  131.  
  132. ••••tar creation (HD->HD, 900k file)
  133.  
  134. StuffIt Deluxe  17 sec
  135. suntar 2.0      16 sec
  136. tar 3.0         12 sec
  137.  
  138. ••••tar creation (HD->floppy disk, 700k directory)
  139.  
  140. suntar 1.1     400 sec
  141. suntar 1.2.1   360 sec
  142. StuffIt Deluxe  (file on a Mac floppy disk) 125 sec
  143. tar 3.0        49 sec
  144. suntar 1.3.3   45 sec        (buffered only towards the floppy)
  145. suntar 2.0     42 sec
  146.  
  147. ••••BinHex creation (HD->ram, 900k file)
  148.  
  149. StuffIt 1.5.1  128 sec
  150. StuffIt Deluxe 110 sec
  151. Downline       95 sec
  152. BinHex 4.0     92 sec
  153. BinHqx DA      51 sec
  154. Compact Pro    47 sec
  155. suntar 2.0      29 sec
  156.  
  157. ••••MacBinary creation (HD->HD, 900k file)
  158.  
  159. UMCP™ Tools     100 sec
  160. suntar 2.0 b8   35 sec                (buffered towards the destination but not the source)
  161. BinHex 5.0      29 sec
  162. StuffIt Deluxe  26 sec
  163. MacBinary II+   17 sec
  164. suntar 2.0      15 sec
  165. MacBinary 1.01  13 sec
  166.  
  167. If you are a programmer and you want to write fast code, this is what
  168. I learnt in the process of speeding up suntar:
  169.  
  170. 1) I/O buffering is always essential: I believe that in many categories
  171.    the faster is the program which uses the largest buffer. In fact, since
  172.    some programs (including suntar) allow you to choose the buffer size,
  173.    in most cases it's meaningless to look for "the fastest" program,
  174.    that depends on how they are configured.  The large jumps in the
  175.    times (e.g. a factor of 2) between two programs are always
  176.    due to different buffering schemes (e.g.: read one char at a time,
  177.    512 bytes, 8k or more). But there is a point at which increasing the
  178.    buffer gets no increase in speed, which depends on the device: for a
  179.    hard disk 8k is good,  for a floppy disk it's better 9k (that's a
  180.    track or half track on 720k or 1440k floppy disks), and very large
  181.    buffers are still useful for an extraction to the same device if
  182.    the source file and the destination file are placed at different
  183.    positions and a large head movement is required every time the
  184.    application loads or flushes a buffer.
  185. 2) only for complex conversions, at least for operations on fast disks,
  186.    it's important a well optimazed algorithm, where most operations
  187.    are done inside a single loop within a single function, with all
  188.    essential variables kept in registers.
  189. 3) for very simple formats (MacBinary, non-compressed PackIt, tar)
  190.    it's important to handle one format only: suntar suffers from its
  191.    number of supported formats, StuffIt Deluxe suffers even more
  192.    (I mean that it's possible and easy to be 50% faster than suntar
  193.    in uncompressed PackIt extraction, no program does that only
  194.    because the PackIt format is obsolete and the original
  195.    PackIt is outperformed anyway also by non-optimized programs).
  196. 4) only if the algorithm should contain some code written by a
  197.    Mathematician, some knowledge of Mathematics is not bad
  198.    (Mathematicians usually write straighforwardly and never worry
  199.    about speed, but in order to rewrite their code you must understand
  200.    what they're doing).
  201. 5) assembly language is useful, but only in special cases: e.g. mcopy
  202.    is three times faster than a standard memcpy, but it would be almost
  203.    as fast written in C: it's the smart algorithm which makes it fast.
  204.    Assembly language is really essential only if you need instructions
  205.    which the C compiler does not exploit (DBRA, SWAP, BTST, all the
  206.    operations involving the processor flags) or exceptionally when you
  207.    need more register variables than the compiler supports.
  208. 6) never forget to measure the speed and compare it to other programs:
  209.    one may believe to have written a wonderfully fast program and then
  210.    discover that a small detail makes it slow.
  211.  
  212.                             1 November 1994
  213.                             Gabriele Speranza